In a network, in particular in a wireless network, it is required to keep every node updated with the currently used value of network configuration parameters to maintain a correct operation for each node of the network. Indeed, it is possible that, due to unscheduled events, like a change in the interference spectrum or location, or due to scheduled events, like a periodic change of cryptographic key, a maintenance entity needs to communicate a new value for a network configuration parameter, like a channel identifier, a network identifier, node identifier or role, identifier of a new coordinator/maintenance entity inside the network, a cryptographic key or a key seed.
However, in some networks, there can be some nodes that are limited in terms of reception opportunities. As an illustration, in a ZigBee network, there may be ZigBee Green Power Devices (ZGPDs), which do not have a battery or are otherwise limited in terms of operational energy. A ZGPD may harvest its own energy, e.g. using solar cells. Such devices can receive data or instructions only at unscheduled opportunities. For example, a ZGPD can be a user-operated battery-less switch that can only receive for a short time once it is actuated by a user and has transmitted its signal. Another example of a ZGPD is a frequently reporting sensor, harvesting energy from its environment, e.g. by means of a photovoltaic cell. The sensor may, e.g., detect temperature, occupancy, or light. Because of their energy budget limitations, those devices are also not able to discover the new parameters via an active search or might not even be able to discover the parameter change.
Given that these devices cannot receive a configuration signal at any arbitrary time, if a reconfiguration of the network occurs in the interval between two reception opportunities of a limited device, this limited device would be unaware of the change in the parameter value. This is likely to cause the limited device to be excluded from the network, since it would still use the previous version of the network parameters and is likely not to be heard by its neighbors which have been updated (e.g. in case of channel changes) or its message may be dropped (e.g. in case of network identifier change or key change). For such wireless limited node to be reintegrated in the network, it requires a special process which is very likely to require manual intervention from the user, can be long and is thus a large maintenance burden. Similar problems are also relevant when not sending network configuration updates but other types of messages that have to reach the limited node, such as for example measurement data, change in the wireless node reporting behavior, e.g. reporting frequency, measurement thresholds, etc.
An example of a method and system trying to overcome these problems is described in the pending Philips patent application EP11305720.2. In said patent application it is proposed to postpone updating the wireless non-limited nodes in the network until the wireless limited node is detected and updated. However, if the network is not aware of the presence of the wireless limited node or if no reception opportunities arise, postponing the update will not work. Undetected nodes will not be updated and will not be part of the network anymore. If no reception opportunity arises at all, the update of the complete system may be postponed or cancelled. If the update does take place, the limited node will not be part of the network anymore
Furthermore, for such wireless limited nodes, it may be impossible to check correctness of their configuration and operation with respect to, e.g., the wireless configuration parameters such as channel, security key, options, peer devices, network, and application operation, like sensor calibration, reporting frequencies and thresholds and application logic, especially on-demand and remotely. Such checks may be required e.g. during scheduled system maintenance operations; or in case of commissioning or debugging the system, e.g. upon addition or replacement of a node in a wireless network, upon control functionality re-configuration, etc. They may be further used for checking reliability of the wireless connection. Further, such checks can be required in periods of prolonged absence of signals transmitted by the wireless limited device (e.g. caused by lack of condition change or user absence).